Developers of many application programs (“applications”) implement the applications so that they can be customized by third parties. To customize an application, a third party develops custom code (e.g., add-ins and document-level customizations) that uses functionality exposed by the application. The custom code may improve the usability of the applications or provide additional functionality (e.g., domain-specific functionality). Such applications are referred to as “host applications” because the custom code is hosted within the process of the application. Developers of applications typically want to encourage the development of custom code for their applications to increase the demand for their applications. As a result, such developers may provide “runtimes” that facilitate the development of custom code. A runtime is code that is loaded along with custom code and provides services to the custom code. These services may include higher-level functionality than exposed by the application or may include domain-specific functionality. When an application is to load and start the execution of custom code, the application may load the runtime and direct the runtime to load and start the execution of the custom code.
Because of the ease of developing custom code as “managed code,” many applications support the execution of custom code in the .NET Framework provided by Microsoft Corporation. The .NET Framework provides a common language runtime (“CLR”) that provides high-level operating system type services to the managed programs (including custom code and applications) and serves as an execution engine for managed programs. The CLR ensures that managed programs do not take any unauthorized action. As such, the CLR acts as a “sandbox” within which managed programs execute. The CLR provides application domains (“appdomains”) in which different managed programs can execute to help ensure that an errant managed program will not unduly affect the execution of another managed program.
Forms allow developers to create new types of email messages to add to the existing mail, calendar, note, and other types of email messages built into an email application. Forms may include user interface elements, such as buttons, text boxes, and so forth, as well as executable code that define the behavior of the form, such as what actions to take when a user clicks a button. Microsoft Office Outlook 2007 introduced a new form technology called form regions. Form regions overcome the limitations of customizing Outlook forms by using form pages in a variety of new ways. For example, form regions can be displayed in the Reading Pane, and can be added to standard forms without creating a derived message class. The older forms framework only allowed executable code to be provided through a scripting language. The new form regions allow developers to write code for a form using managed code (e.g., using .NET) or other Component Object Model (COM)-based languages. In previous versions of Outlook, third parties who wanted to extend the Outlook user interface (UI) to include custom functionality were restricted by limited support for custom forms in Outlook. Often, when you wanted to add a few fields or make a small modification to the form, Outlook required you to redesign the entire form.
In Outlook 2007, form regions allow more ways to add UI to standard forms and simplify the process of designing custom UI. For example, through an adjoining form region, a developer can extend any existing form with additional fields or controls. These adjoining form regions are displayed at the bottom of the first page of a form, and each adjoining form region is collapsible. Developers can also add a separate form region, which is displayed as a full additional form page and can appear on any existing standard form or custom form. Another benefit of using form regions is that form regions support visual themes. In the past, developers were required to use custom Microsoft ActiveX controls or advanced workarounds to enable a themed look to custom forms. With form regions, all of the controls that come with Outlook 2007 inherit the Microsoft Windows theme.
Although popular development tools, such as Microsoft Visual Studio 2005, provide support for developing Office add-ins, these tools are missing some key components that are useful for writing Outlook 2007 COM add-ins in managed code, and in particular Outlook form regions. Although using Microsoft Visual Studio Tools for the Microsoft Office System (VSTO) would be the preferred development approach for writing Outlook form region controls, VSTO is currently incompatible with Office 2007 applications. In addition, these development tools do not have a comprehensive awareness of the interfaces and other points of contact between the forms hosting environment provided by Outlook and the controls written by developers. Therefore, developers must either write traditional ActiveX controls and forego the conveniences of the managed environment, or write newer managed controls and invest substantial extra effort to manually describe the interfaces needed to communicate with Outlook. The lack of understanding of the forms region architecture by popular development tools adds additional difficulty for the developer in all stages of the development process, including design, development, and debugging. These difficulties increase the amount of time spent by the developer overcoming hurdles of the environment and decrease the time available to the developer to spend on improving her component.